home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000758_marca@wintermu….ncsa.uiuc.edu _Sat Mar 13 11:58:25 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <marca@wintermute.ncsa.uiuc.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA26822; Sat, 13 Mar 93 11:58:25 MET
  4. Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA14123; Sat, 13 Mar 1993 12:16:10 +0100
  6. Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA24190
  7.   (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 13 Mar 93 05:16:09 -0600
  8. Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
  9.     for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA16417; Sat, 13 Mar 93 05:18:03 -0800
  10. Date: Sat, 13 Mar 93 05:18:03 -0800
  11. From: marca@ncsa.uiuc.edu (Marc Andreessen)
  12. Message-Id: <9303131318.AA16417@wintermute.ncsa.uiuc.edu>
  13. To: Guido.van.Rossum@cwi.nl
  14. Cc: www-talk@nxoc01.cern.ch
  15. Subject: Re: proposed new tag: IMG 
  16. In-Reply-To: <9303131054.AA05457=guido@voorn.cwi.nl>
  17. References: <9303130632.AA14200@wintermute.ncsa.uiuc.edu>
  18.     <9303131054.AA05457=guido@voorn.cwi.nl>
  19. X-Md4-Signature: 0adad6d1eb30b6578b70c6dff2338d07
  20.  
  21. Guido.van.Rossum@cwi.nl writes:
  22. > >We're not prepared to support INCLUDE/EMBED at this point; it raises a
  23. > >number of nasty issues that are quite separate from the idea of
  24. > >inlined images.  For example, what happens if one EMBEDS a document
  25. > >that in turn EMBEDS the first document?  Oops.
  26. > 
  27. > I would consider this an error of the author that needs to be detected
  28. > to protect the browser.  It only requires maintaining a stack of
  29. > nested EMBEDS.
  30.  
  31. Still, I'd argue the principle is still there.  If a document has to
  32. be pieced together on the fly, it could get arbitrarily complex, and
  33. even if that were limited, we'd certainly start experiencing major
  34. hits on performance for documents structured in this way.  This
  35. essentially throws the single-hop principle of WWW out the door (well,
  36. IMG does that too, but for a very specific reason and in a very
  37. limited sense) --- are we sure we want to do that?
  38.  
  39. > Some other hypertext systems do this, in a sense: in Guide there are,
  40. > apart from real GOTO stype hyperlinks, also "folds" (I think they are
  41. > called) which are sort of embedded documents that you can open and
  42. > close.  The advantage in certain situations is that opening a fold
  43. > retains more context than following a link.  It feels like using an
  44. > outline processor, which is rather pleasant (for certain kinds of
  45. > information).
  46.  
  47. Would be nice to be able to do this, but it would essentially be just
  48. a fancy multi-windowed version of the current distributed hypertext
  49. model, right?  Instead of jumping to whole new documents, the act of
  50. triggering a link would open up more information in the current
  51. context.  That doesn't require EMBED functionality...
  52.  
  53. > PS. I keep hearing about supporting MIME.  Is there consensus on the
  54. > form this should take?  (I remeber getting in an unpleasant fight with
  55. > Dan Connolly about this once -- BTW is he still with us?)
  56.  
  57. Mosaic currently recognizes documents suffixed .mime and throws 'em
  58. off to metamail.  Some support for MIME is in Tim's new WWW library
  59. (although I haven't looked very closely at it).  Other than that, I'm
  60. not sure what the consensus exactly is.  And Dano's history, I do
  61. believe...
  62.  
  63. Marc
  64.  
  65. --
  66. Marc Andreessen
  67. Software Development Group
  68. National Center for Supercomputing Applications
  69. marca@ncsa.uiuc.edu
  70.